home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 083 / phnxdoc.arc / PHNXDOC.7 < prev    next >
Text File  |  1987-12-04  |  13KB  |  264 lines
  1.  
  2.  
  3.       PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987
  4.  
  5.          7.0  PHOENIX NETWORKING
  6.  
  7.              Before we get started talking about how Phoenix handles its
  8.              network system, we must give you a little history about this
  9.              process.  First, this whole network concept was dreamed up by a
  10.              man named Tom Jennings, who, among other things, is responsible
  11.              for a bulletin board program called "FIDO".  Tom had a wonderful
  12.              idea of connecting these bulletin boards together at a
  13.              predetermined time to send mail, or packets, to each other.  We
  14.              thought enough of Tom's idea to include his FIDONET concept in
  15.              Phoenix.
  16.  
  17.              NOTE: At present, Phoenix and Fido are NOT fully compatable.
  18.  
  19.  
  20.          7.1  NET-MAIL DESCRIPTION
  21.  
  22.              (NOTE:  Many of the following notes were taken out of Tom
  23.              Jennings's "FIDO'S Complete Operating Manual".)
  24.  
  25.              The purpose of this net mail concept is to link Phoenix
  26.              Bulletin Board systems together for automatic message
  27.              transfers.
  28.  
  29.              This Net system is a true dial up packet switch network system
  30.              that supports many different topologies.  It supports routing,
  31.              message forwarding, scheduling and uses a tuned collision
  32.              detection algorithm over normal phone lines, for the lowest
  33.              possible cost and highest efficiency.
  34.  
  35.              The simplest scheme, and the one to set initially, supports
  36.              point-to-point messages.  Most major geographical area have a
  37.              host that will accept mail for itself and its local nodes.
  38.  
  39.              After you have contacted any other Phoenix sysops in
  40.              your area, you can tie into their local network, and take
  41.              advantage of the lower cost.  Each local area runs things
  42.              differently, and their policies cannot be covered here.  If you
  43.              can't find your local region or host, contact Phoenix 800/1 at
  44.              316-788-3630, where you can find the latest node list and other
  45.              files to help steer you in the right direction.
  46.  
  47.              The original FidoNET design was built around the current
  48.              Bulletin Board architecture which is basically: an unknown
  49.              number of completely independent, stand alone systems, with
  50.              extremely low overhead in both maintenance and cost.  The
  51.              Phoenix Net System was designed to be compatible with this, in
  52.              that it should involve:
  53.                     1.  No extra work for the SysOp.
  54.                     2.  No effect on normal BBS operations.
  55.                     3.  No unexpected extra costs.
  56.                     4.  No effect upon system reliability.
  57.              Phoenix handles this automatically, and requires no
  58.              extra work, once set up.  Other than the effect of allowing
  59.              Network-wide message traffic, the only other affect upon the
  60.              current BBS is that it is "down" to normal traffic (regular
  61.              callers) during the National net time of 1am to 2am PST
  62.              (4am to 5am EST). Please be sure to correctly figure your
  63.              time zone.
  64.  
  65.  
  66.  
  67.  
  68.       PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987
  69.  
  70.              Costs, if any, are controlled by the sysops.  Unless
  71.              specifically enabled, mail will not be sent out from a node.
  72.              Remember, sending mail costs money; receiving packets is free.
  73.              Phoenix provides accounting and cost limitation functions (all
  74.              automatic) to prevent unauthorized mail from being sent.  There
  75.              can also be "free" traffic to non-toll call nodes as well as
  76.              limitations put on long distant calls.  The usual privilege
  77.              levels can be applied to each of the mail commands, to control
  78.              their use.
  79.  
  80.              Net-mail success/failure does not in anyway affect BBS
  81.              operations.  Failure to make a connection and transmit a packet,
  82.              or errors during incoming packets, affect only the mail sent or
  83.              received.  In the case of transmission, the message will not be
  84.              sent, nor will charges (if any) be applied to the sender's
  85.              credit account.
  86.  
  87.              For a paying system, the sysop must occasionally set the user's
  88.              credit, using the "Utilities for the SysOp" section and
  89.              crediting the user's account.  If reasonably large sums are used
  90.              as a minimum ($5.00 or more), this will not need to be done more
  91.              than once every few weeks.
  92.  
  93.          7.2  GETTING A NET/NODE NUMBER
  94.  
  95.              In order to obtain a Phoenix net/node number and join in
  96.              the PhoenixNet, you must have had your Phoenix board running
  97.              for at least 1 week.  During this
  98.              time you should set your Net/Node number to 800/999
  99.              (that is Net 800, Node 999). Do this in CONFIG.
  100.              This indicates that you are awaiting a net/node number.
  101.              With this temporary net/node number set, you must send a
  102.              NetMail message (so we know you are indeed running the Net)
  103.              to Bennett Griffin at 800/1  (The Aztec BBS)
  104.              with the following information:
  105.  
  106.                     Sysop Name
  107.                     Board Name
  108.                     Data Number
  109.                     Sysop Home Number
  110.                     Board Location
  111.                     Time Zone
  112.                     Sysop Age
  113.  
  114.  
  115.              After you have sent this information to 800/1,
  116.              it will be processed and you will be issued a Net/Node number.
  117.              You will be notified of your net/node number and you
  118.              will then be added to the nodelist.
  119.              If you haven't received your net/node number within a week,
  120.              inquire at 800/1 as to why and we'll check on it
  121.              (we stay pretty busy!).
  122.  
  123.  
  124.              Note:  Applictaions MUST be sent through NetMail...
  125.              All others will NOT be processed.
  126.              Also, applications must be sent with a net/node number of 800/999.
  127.             'Self-assigned' node numbers will NOT be processed at all.
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.       PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987
  135.  
  136.        7.3  HOW IS THE NET/NODE SYSTEM ORGANIZED?
  137.  
  138.             After trying to analyze why people use the Net-Mail feature of
  139.             Phoenix we came up with one common reason: "Location".  More
  140.             than any other reason, callers use the system because they
  141.             want to contact a person in a certain area of the country.
  142.  
  143.             For this reason, Nets will be assigned by State.
  144.  
  145.             Note, the Phoenix Development/GeneSys Project Sites
  146.             are all listed in Net 800.
  147.             This is so you have easy access to the one closest to you for help
  148.             and assistance, and, should the need arise, a place to report
  149.             the ugly bugs! (YUCK.)!
  150.  
  151.             Nodes are Systems within each net.  Each Net can hold up to
  152.             32767 nodes before we have to open another Net number.
  153.  
  154.  
  155.          7.4  NET-MAIL OPERATION
  156.  
  157.              Within Phoenix is the Net-Mail module which is run as specified
  158.              by the scheduler.  This module is a time driven system, and the
  159.              national time slot is at 1:00 AM Pacific Standard Time, 4:00 AM
  160.              for you on the east coast.  During normal Phoenix operation,
  161.              users can enter messages, and, during the Net-Mail time, these
  162.              messages are made into packets and sent to the right
  163.              destination.  The messages may be destined to any one or more of
  164.              the available remote nodes in the nodelist.
  165.  
  166.              At the predetermined time, the Net-Mail module takes control.
  167.              Within 5 minutes of the scheduled event Phoenix will
  168.              automatically drop DTR so users do not get on the system.  If a
  169.              user is on the system, Phoenix will inform them of the upcoming
  170.              scheduled event and give them a chance to log-off, or, if
  171.              needed, Phoenix will log them off just as if they exceeded
  172.              their time limit.  The Net-Mail module then (if enabled) creates
  173.              mail packets, one per node, containing the messages for each
  174.              node.  If there is no mail to a node, no packet is created, and
  175.              no call is made to that system.
  176.  
  177.              After the outgoing packets are made, Phoenix alternately waits
  178.              for calls and attempts to place calls.  Mail packet transfers
  179.              are done on a collision detection basis. After the first few
  180.              collisions, the network synchronizes. If there are a number of
  181.              nodes to send mail to, each one is called in turn, until all are
  182.              sent, or mail time is over. If it fails with one node, it goes
  183.              on to the next, and repeats the failed one only after trying all
  184.              of the others first.
  185.  
  186.              In between outgoing calls (if any) Phoenix delays a random
  187.              interval, during which it waits for incoming calls.  This
  188.              interval, along with the redial algorithm, synchronizes the net
  189.              after the initial collisions.
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.       PHOENIX REMOTE COMMUNICATIONS SYSTEM                  DECEMBER 4, 1987
  201.  
  202.              If an incoming call is detected, it attempts connection with it.
  203.              The baud rate is determined (same as for a normal caller in
  204.              Phoenix), a message to human callers is displayed (warning them
  205.              that the board is accepting only other Phoenix or Fido Nodes),
  206.              and a synchronization process is started. This process must
  207.              complete within 60 seconds, or the call is terminated. Once
  208.              synchronized, the packet transfer is made.  The receiver just
  209.              stores that packet for later use, and then disconnects.
  210.  
  211.              Whenever an incoming call is received, Phoenix calls out
  212.              immediately afterwards (assuming there are calls to be made),
  213.              since there is a high probability that the line is now clear.
  214.              This helps synchronize the network.
  215.  
  216.              To place an outgoing call, the sender dials the number, performs
  217.              the sync process mentioned above, and transfers its outgoing
  218.              packet.  (Messages to a given node are again checked against the
  219.              node list at mail time; if they do not match, the packet is not
  220.              sent, and an error is logged.) If the transfer was successful,
  221.              the destination node number is deleted from the sender's list of
  222.              nodes to call.
  223.  
  224.              The collision detect algorithm is optimized such that during the
  225.              first few minutes of mail time, there are many collisions, after
  226.              which the net synchronizes, and none or few collisions occur.
  227.  
  228.              When mail time is over, Phoenix deletes all its outgoing
  229.              packets that were assembled, and for each one that was sent
  230.              successfully, marks those messages (in the mail area) as SENT,
  231.              so the originator can tell if they went out or not. Then, the
  232.              incoming packets are unassembled, and the messages placed
  233.              sequentially in the mail area. These packets are then deleted.
  234.  
  235.              If any mail at all was sent, the user credits are balanced. This
  236.              is somewhat unsatisfactory, as it balances the accounts even if
  237.              the mail was not sent. This is to prevent extremely long
  238.              processing time necessary to account for each message and user.
  239.              (Users lists run upwards of 600 entries typically; on a floppy-
  240.              based system, this would become unworkable.)
  241.  
  242.              Net-Mail then terminates, and invokes Phoenix for another day.
  243.              Messages received are then accessible like any other message
  244.              and placed in the message area marked for Net-Mail.
  245.  
  246.              All of your Net Activities are recorded in a file called
  247.              "MAILER.LOG" which can be viewed with any listing type program,
  248.              by using the DOS command TYPE, or by placing the filename in
  249.              a dumpfile class menu call (the best way).
  250.  
  251.              WATCH FOR A TOTALLY NEW AND ADVANCED ELECTRONIC MAIL SYSTEM
  252.              IN Phoenix v3.0.
  253.              It will have features most have only dreamed about.
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.